Rename tag fields from metadata to tags#140
Conversation
✱ Stainless preview buildsThis PR will update the
|
|
taking liberty to merge because it's just a naming-related follow up from another PR with no functional changes |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| ID string `json:"id"` | ||
| Status string `json:"status"` | ||
| Metadata tags.Metadata `json:"metadata,omitempty"` | ||
| Tags tags.Tags `json:"tags,omitempty"` |
There was a problem hiding this comment.
JSON tag rename silently drops persisted tags data
High Severity
Changing the JSON struct tag from json:"metadata,omitempty" to json:"tags,omitempty" on all on-disk storage structs (buildMetadata, imageMetadata, storedIngress, volume storedMetadata, Snapshot, and instance StoredMetadata) means existing JSON files persisted with the "metadata" key will silently fail to deserialize into the new Tags field. Any resources that previously had tags will lose them after this update with no error or warning. The same applies to the instance StoredMetadata struct which has no explicit JSON tags — the field rename from Metadata to Tags changes the default key. This is not a "pure rename" as the PR describes; it's a breaking on-disk format change causing silent data loss.
Additional Locations (2)
There was a problem hiding this comment.
Risk assessment: Medium-High.
Evidence from the code diff:
- User-facing API contract changes in
openapi.yamlrename schema/property names frommetadatatotagsacross multiple request/response models. - Corresponding generated API surface in
lib/oapi/oapi.goand request handling/domain structs incmd/api/api/*andlib/*are updated broadly. - This is a cross-cutting production change across builds/devices/images/instances/snapshots/volumes with no compatibility shim for existing
metadataclients.
Decision:
- Review is required.
- I did not approve this PR.
- Requested reviewers:
rgarcia,hiroTamada.
1 participant
Summary
metadatatotagsacross OpenAPI, generated OAPI types, API handlers, and domain structslib/tagsto useTagsandErrInvalidTagsTagsconsistentlyNotes
Validation
make oapi-generatego test ./lib/tags ./lib/images ./lib/snapshot ./lib/volumes ./lib/ingress ./lib/oapi -run TestDoesNotExistNote
Medium Risk
Medium risk because it is an API contract change (request/response fields and query params move from
metadatatotags) with no backward-compatibility, which can break existing clients and persisted JSON expectations.Overview
Renames the user-facing tagging contract from
metadatatotagsacross the system. API request/response payloads and list filters now usetags(including deepObject query params like?tags[team]=...), andCreateBuildmultipart parsing switches frommetadatatotags.Domain/resource structs and on-disk JSON representations are updated to store
tagsinstead ofmetadatafor builds, devices, images, ingresses, instances, snapshots, and volumes; validation/cloning/matching helpers inlib/tagsare renamed accordingly (includingErrInvalidTags). Tests and generatedlib/oapitypes/spec are updated to match the new field names, with no compatibility shim for the oldmetadatafields.Written by Cursor Bugbot for commit 2b02226. This will update automatically on new commits. Configure here.